Structure of RIBs in branch

• Portal shows Switcher by default
• Switcher can switch to HelloWorld
• HelloWorld embeds Small
• Small can trigger attaching Big directly to Portal (by clicking button)
• Big embeds Small again, so can test multiple portal additions

To test

• Go to Hello in menu, tap SHOW BIG as many times as you wish
• Check with layout inspector that only one RIB child layout is actually attached to Switcher
• Open a couple of Big instances in chain, leave app with don't keep Activities, restore, check Big is properly rebuilt (even that Portal doesn't directly know about this Node), check back stack is properly restored as well

How it's done

• Node that's attached through Portal is actually attached both in the view tree and both as a logical child of the Portal implementing Router, through a Configuration (check PortalRouter), even though it knows nothing about the child directly
• The tricky part is that Portal needs to know how to build that remote Node, so that it can restore it later
• Introduced term: anchor, which is the parent that wants to build the Node - it's the same as actual parent in all default cases, but when showing through a Portal, anchor is the triggering parent, while actual parent will be the Portal implementing Node
• Node contains AncestryInfo which can be used to back track a chain of Configurations through anchors that can be used to reach it again
• as all Configurations are Parcelable, so is a List<Parcelable> of them, which is what PortalRouter stores in its Portal configuration
• after restoration, the chain can be resolved again to reach the builder of the Node to be added as full screen again

Implications

• Correct in decoupling, as Portal host Node doesn't know about actual attached Node
• Correct in statefulness & restoration
• Correct in view-tree efficiency, all off-screen Nodes are detached from view
• Correct in lifecycle handling, all off-screen Nodes are stopped, as they go to back stack
• Probably can be used to host Overlay dialogs through Portal as well, with proper full lifecycle implications (solving tricky case outlined in Lifecycle events can be missing #44), but needs further investigation
• Example implementation of client code in SmallInteractor & SmallRouter shows how its configuration of FullScreen.ShowBig is both part of its Configuration sealed class (requiring exhaustive when in resolveConfiguration), but also not part of its Content type, meaning it cannot even be pushed to SmallRouter accidentally (win)
• Client code all-in-all remains extremely light-weight (win)
• Implementation on framework side contains the fewest amount of moving parts, not using special workarounds, just building on top of existing functionality (win)

Room for improvement

• TODO comments in PortalRouter cover non-urgent cases that can be improved later
• FIXME comment in Node about moving AncestryInfo to constructor is a BC breaking change, will be done in another ticket. Right now it's fine the way it is, it will be needed for the resolution of other TODO comments.